home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1268 < prev    next >
Text File  |  1995-07-25  |  31KB  |  731 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         Y. Rekhter
  8. Request for Comments: 1268        T.J. Watson Research Center, IBM Corp.
  9. Obsoletes: RFC 1164                                             P. Gross
  10.                                                                      ANS
  11.                                                                  Editors
  12.                                                             October 1991
  13.  
  14.  
  15.        Application of the Border Gateway Protocol in the Internet
  16.  
  17. Status of this Memo
  18.  
  19.    This protocol is being developed by the Border Gateway Protocol
  20.    Working Group (BGP) of the Internet Engineering Task Force (IETF).
  21.    This RFC specifies an IAB standards track protocol for the Internet
  22.    community, and requests discussion and suggestions for improvements.
  23.    Please refer to the current edition of the "IAB Official Protocol
  24.    Standards" for the standardization state and status of this protocol.
  25.    Distribution of this memo is unlimited.
  26.  
  27. Abstract
  28.  
  29.    This document, together with its companion document, "A Border
  30.    Gateway Protocol (BGP-3)", define an inter-autonomous system routing
  31.    protocol for the Internet.  "A Border Gateway Protocol (BGP-3)"
  32.    defines the BGP protocol specification, and this document describes
  33.    the usage of the BGP in the Internet.
  34.  
  35.    Information about the progress of BGP can be monitored and/or
  36.    reported on the BGP mailing list (iwg@rice.edu).
  37.  
  38. Table of Contents
  39.  
  40.    1. Introduction...................................................   2
  41.    2. BGP Topological Model..........................................   3
  42.    3. BGP in the Internet............................................   4
  43.    4. Policy Making with BGP.........................................   5
  44.    5. Path Selection with BGP........................................   6
  45.    6. Required set of supported routing policies.....................   8
  46.    7. Conclusion.....................................................   9
  47.    Appendix A. The Interaction of BGP and an IGP.....................   9
  48.    References........................................................  12
  49.    Security Considerations...........................................  12
  50.    Authors' Addresses................................................  13
  51.  
  52. Acknowledgements
  53.  
  54.    This document was original published as RFC 1164 in June 1990,
  55.  
  56.  
  57.  
  58. BGP Working Group                                               [Page 1]
  59.  
  60. RFC 1268           Application of BGP in the Internet       October 1991
  61.  
  62.  
  63.    jointly authored by Jeffrey C. Honig (Cornell University), Dave Katz
  64.    (MERIT), Matt Mathis (PSC), Yakov Rekhter (IBM), and Jessica Yu
  65.    (MERIT).
  66.  
  67.    The following also made key contributions to RFC 1164 -- Guy Almes
  68.    (ANS, then at Rice University), Kirk Lougheed (cisco Systems), Hans-
  69.    Werner Braun (SDSC, then at MERIT), and Sue Hares (MERIT).
  70.  
  71.    This updated version of the document is the product of the IETF BGP
  72.    Working Group with Phillip Gross (ANS) and Yakov Rekhter (IBM) as
  73.    editors.  John Moy (Proteon) contributed Section 6 "Recommended set
  74.    of supported routing policies".
  75.  
  76.    We also like to explicitly thank Bob Braden (ISI) for the review of
  77.    this document as well as his constructive and valuable comments.
  78.  
  79. 1. Introduction
  80.  
  81.    This memo describes the use of the Border Gateway Protocol (BGP) [1]
  82.    in the Internet environment. BGP is an inter-Autonomous System
  83.    routing protocol. The network reachability information exchanged via
  84.    BGP provides sufficient information to detect routing loops and
  85.    enforce routing decisions based on performance preference and policy
  86.    constraints as outlined in RFC 1104 [2]. In particular, BGP exchanges
  87.    routing information containing full AS paths and enforces routing
  88.    policies based on configuration information.
  89.  
  90.    All of the discussions in this paper are based on the assumption that
  91.    the Internet is a collection of arbitrarily connected Autonomous
  92.    Systems. That is, the Internet will be modeled as a general graph
  93.    whose nodes are AS's and whose edges are connections between pairs of
  94.    AS's.
  95.  
  96.    The classic definition of an Autonomous System is a set of routers
  97.    under a single technical administration, using an interior gateway
  98.    protocol and common metrics to route packets within the AS, and using
  99.    an exterior gateway protocol to route packets to other AS's. Since
  100.    this classic definition was developed, it has become common for a
  101.    single AS to use several interior gateway protocols and sometimes
  102.    several sets of metrics within an AS. The use of the term Autonomous
  103.    System here stresses the fact that, even when multiple IGPs and
  104.    metrics are used, the administration of an AS appears to other AS's
  105.    to have a single coherent interior routing plan and presents a
  106.    consistent picture of which networks are reachable through it. From
  107.    the standpoint of exterior routing, an AS can be viewed as
  108.    monolithic: networks within an AS must maintain connectivity via
  109.    intra-AS paths.
  110.  
  111.  
  112.  
  113.  
  114. BGP Working Group                                               [Page 2]
  115.  
  116. RFC 1268           Application of BGP in the Internet       October 1991
  117.  
  118.  
  119.    AS's are assumed to be administered by a single administrative
  120.    entity, at least for the purposes of representation of routing
  121.    information to systems outside of the AS.
  122.  
  123. 2. BGP Topological Model
  124.  
  125.    When we say that a connection exists between two AS's, we mean two
  126.    things:
  127.  
  128.       Physical connection:  There is a shared network between the two
  129.       AS's, and on this shared network each AS has at least one border
  130.       gateway belonging to that AS. Thus the border gateway of each AS
  131.       can forward packets to the border gateway of the other AS without
  132.       resort to Inter-AS or Intra-AS routing.
  133.  
  134.       BGP connection:  There is a BGP session between BGP speakers on
  135.       each of the AS's, and this session communicates to each connected
  136.       AS those routes through the physically connected border gateways
  137.       of the other AS that can be used for specific networks. Throughout
  138.       this document we place an additional restriction on the BGP
  139.       speakers that form the BGP connection: they must themselves share
  140.       the same network that their border gateways share. Thus, a BGP
  141.       session between the adjacent AS's requires no support from either
  142.       Inter-AS or Intra-AS routing. Cases that do not conform to this
  143.       restriction fall outside the scope of this document.
  144.  
  145.    Thus, at each connection, each AS has one or more BGP speakers and
  146.    one or more border gateways, and these BGP speakers and border
  147.    gateways are all located on a shared network. Note that BGP speakers
  148.    do not need to be a border gateway, and vice versa. Paths announced
  149.    by a BGP speaker of one AS on a given connection are taken to be
  150.    feasible for each of the border gateways of the other AS on the same
  151.    connection, i.e. indirect neighbors are allowed.
  152.  
  153.    Much of the traffic carried within an AS either originates or
  154.    terminates at that AS (i.e., either the source IP address or the
  155.    destination IP address of the IP packet identifies a host on a
  156.    network directly connected to that AS).  Traffic that fits this
  157.    description is called "local traffic". Traffic that does not fit this
  158.    description is called "transit traffic". A major goal of BGP usage is
  159.    to control the flow of transit traffic.
  160.  
  161.    Based on how a particular AS deals with transit traffic, the AS may
  162.    now be placed into one of the following categories:
  163.  
  164.       stub AS: an AS that has only a single connection to one other AS.
  165.       Naturally, a stub AS only carries local traffic.
  166.  
  167.  
  168.  
  169.  
  170. BGP Working Group                                               [Page 3]
  171.  
  172. RFC 1268           Application of BGP in the Internet       October 1991
  173.  
  174.  
  175.       multihomed AS: an AS that has connections to more than one other
  176.       AS, but refuses to carry transit traffic.
  177.  
  178.       transit AS: an AS that has connections to more than one other AS,
  179.       and is designed (under certain policy restrictions) to carry both
  180.       transit and local traffic.
  181.  
  182.    Since a full AS path provides an efficient and straightforward way of
  183.    suppressing routing loops and eliminates the "count-to-infinity"
  184.    problem associated with some distance vector algorithms, BGP imposes
  185.    no topological restrictions on the interconnection of AS's.
  186.  
  187. 3. BGP in the Internet
  188.  
  189.    3.1 Topology Considerations
  190.  
  191.    The overall Internet topology may be viewed as an arbitrary
  192.    interconnection of transit, multihomed, and stub AS's.  In order to
  193.    minimize the impact on the current Internet infrastructure, stub and
  194.    multihomed AS's need not use BGP.  These AS's may run other protocols
  195.    (e.g., EGP) to exchange reachability information with transit AS's.
  196.    Transit AS's using BGP will tag this information as having been
  197.    learned by some method other than BGP. The fact that BGP need not run
  198.    on stub or multihomed AS's has no negative impact on the overall
  199.    quality of inter-AS routing for traffic not local to the stub or
  200.    multihomed AS's in question.
  201.  
  202.    However, it is recommended that BGP may be used for stub and
  203.    multihomed AS's as well, providing an advantage in bandwidth and
  204.    performance over some of the currently used protocols (such as EGP).
  205.    In addition, this would result in less need for the use of defaults
  206.    and in better choices of Inter-AS routes for multihomed AS's.
  207.  
  208. 3.2 Global Nature of BGP
  209.  
  210.    At a global level, BGP is used to distribute routing information
  211.    among multiple Autonomous Systems. The information flows can be
  212.    represented as follows:
  213.  
  214.                  +-------+         +-------+
  215.            BGP   |  BGP  |   BGP   |  BGP  |   BGP
  216.         ---------+       +---------+       +---------
  217.                  |  IGP  |         |  IGP  |
  218.                  +-------+         +-------+
  219.  
  220.                  <-AS A-->         <--AS B->
  221.  
  222.    This diagram points out that, while BGP alone carries information
  223.  
  224.  
  225.  
  226. BGP Working Group                                               [Page 4]
  227.  
  228. RFC 1268           Application of BGP in the Internet       October 1991
  229.  
  230.  
  231.    between AS's, a combination of BGP and an IGP carries information
  232.    across an AS.  Ensuring consistency of routing information between
  233.    BGP and an IGP within an AS is a significant issue and is discussed
  234.    at length later in Appendix A.
  235.  
  236. 3.3 BGP Neighbor Relationships
  237.  
  238.    The Internet is viewed as a set of arbitrarily connected AS's. BGP
  239.    speakers in each AS communicate with each other to exchange network
  240.    reachability information based on a set of policies established
  241.    within each AS. Routers that communicate directly with each other via
  242.    BGP are known as BGP neighbors. BGP neighbors can be located within
  243.    the same AS or in different AS's. For the sake of discussion, BGP
  244.    communications with neighbors in different AS's will be referred to
  245.    as External BGP, and with neighbors in the same AS as Internal BGP.
  246.  
  247.    There can be as many BGP speakers as deemed necessary within an AS.
  248.    Usually, if an AS has multiple connections to other AS's, multiple
  249.    BGP speakers are needed. All BGP speakers representing the same AS
  250.    must give a consistent image of the AS to the outside. This requires
  251.    that the BGP speakers have consistent routing information among them.
  252.    These gateways can communicate with each other via BGP or by other
  253.    means. The policy constraints applied to all BGP speakers within an
  254.    AS must be consistent. Techniques such as using tagged IGP (see
  255.    A.2.2) may be employed to detect possible inconsistencies.
  256.  
  257.    In the case of External BGP, the BGP neighbors must belong to
  258.    different AS's, but share a common network. This common network
  259.    should be used to carry the BGP messages between them. The use of BGP
  260.    across an intervening AS invalidates the AS path information. An
  261.    Autonomous System number must be used with BGP to specify which
  262.    Autonomous System the BGP speaker belongs to.
  263.  
  264. 4. Policy Making with BGP
  265.  
  266.    BGP provides the capability for enforcing policies based on various
  267.    routing preferences and constraints. Policies are not directly
  268.    encoded in the protocol. Rather, policies are provided to BGP in the
  269.    form of configuration information.
  270.  
  271.    BGP enforces policies by affecting the selection of paths from
  272.    multiple alternatives, and by controlling the redistribution of
  273.    routing information.  Policies are determined by the AS
  274.    administration.
  275.  
  276.    Routing policies are related to political, security, or economic
  277.    considerations. For example, if an AS is unwilling to carry traffic
  278.    to another AS, it can enforce a policy prohibiting this. The
  279.  
  280.  
  281.  
  282. BGP Working Group                                               [Page 5]
  283.  
  284. RFC 1268           Application of BGP in the Internet       October 1991
  285.  
  286.  
  287.    following are examples of routing policies that can be enforced with
  288.    the use of BGP:
  289.  
  290.       1. A multihomed AS can refuse to act as a transit AS for other
  291.          AS's.  (It does so by not advertising routes to networks other
  292.          than those directly connected to it.)
  293.  
  294.       2. A multihomed AS can become a transit AS for a restricted set of
  295.          adjacent AS's, i.e., some, but not all, AS's can use multihomed
  296.          AS as a transit AS. (It does so by advertising its routing
  297.          information to this set of AS's.)
  298.  
  299.       3. An AS can favor or disfavor the use of certain AS's for
  300.          carrying transit traffic from itself.
  301.  
  302.    A number of performance-related criteria can be controlled with the
  303.    use of BGP:
  304.  
  305.       1. An AS can minimize the number of transit AS's. (Shorter AS
  306.          paths can be preferred over longer ones.)
  307.  
  308.       2. The quality of transit AS's. If an AS determines that two or
  309.          more AS paths can be used to reach a given destination, that
  310.          AS can use a variety of means to decide which of the candidate
  311.          AS paths it will use. The quality of an AS can be measured by
  312.          such things as diameter, link speed, capacity, tendency to
  313.          become congested, and quality of operation. Information about
  314.          these qualities might be determined by means other than BGP.
  315.  
  316.       3. Preference of internal routes over external routes.
  317.  
  318.    For consistency within an AS, equal cost paths, resulting from
  319.    combinations of policies and/or normal route selection procedures,
  320.    must be resolved in a consistent fashion.
  321.  
  322.    Fundamental to BGP is the rule that an AS advertises to its
  323.    neighboring AS's only those routes that it uses. This rule reflects
  324.    the "hop-by-hop" routing paradigm generally used by the current
  325.    Internet.
  326.  
  327. 5. Path Selection with BGP
  328.  
  329.    One of the major tasks of a BGP speaker is to evaluate different
  330.    paths to a destination network from its border gateways at that
  331.    connection, select the best one, apply applicable policy constraints,
  332.    and then advertise it to all of its BGP neighbors at that same
  333.    connection. The key issue is how different paths are evaluated and
  334.    compared.
  335.  
  336.  
  337.  
  338. BGP Working Group                                               [Page 6]
  339.  
  340. RFC 1268           Application of BGP in the Internet       October 1991
  341.  
  342.  
  343.    In traditional distance vector protocols (e.g., RIP) there is only
  344.    one metric (e.g., hop count) associated with a path. As such,
  345.    comparison of different paths is reduced to simply comparing two
  346.    numbers. A complication in Inter-AS routing arises from the lack of a
  347.    universally agreed-upon metric among AS's that can be used to
  348.    evaluate external paths. Rather, each AS may have its own set of
  349.    criteria for path evaluation.
  350.  
  351.    A BGP speaker builds a routing database consisting of the set of all
  352.    feasible paths and the list of networks reachable through each path.
  353.    For purposes of precise discussion, it's useful to consider the set
  354.    of feasible paths for a given destination network. In most cases, we
  355.    would expect to find only one feasible path. However, when this is
  356.    not the case, all feasible paths should be maintained, and their
  357.    maintenance speeds adaptation to the loss of the primary path. Only
  358.    the primary path at any given time will ever be advertised.
  359.  
  360.    The path selection process can be formalized by defining a partial
  361.    order over the set of all feasible paths to a given destination
  362.    network. One way to define this partial order is to define a function
  363.    that maps each full AS path to a non-negative integer that denotes
  364.    the path's degree of preference. Path selection is then reduced to
  365.    applying this function to all feasible paths and choosing the one
  366.    with the highest degree of preference.
  367.  
  368.    In actual BGP implementations, criteria for assigning degree of
  369.    preferences to a path are specified in configuration information.
  370.  
  371.    The process of assigning a degree of preference to a path can be
  372.    based on several sources of information:
  373.  
  374.       1. Information explicitly present in the full AS path.
  375.  
  376.       2. A combination of information that can be derived from the full
  377.          AS path and information outside the scope of BGP (e.g., policy
  378.          routing constraints provided at configuration).
  379.  
  380.    Possible criteria for assigning a degree of preference to a path are:
  381.  
  382.       - AS count. Paths with a smaller AS count are generally better.
  383.  
  384.       - Policy consideration. BGP supports policy-based routing based
  385.         on the controlled distribution of routing information.  A BGP
  386.         speaker may be aware of some policy constraints (both within
  387.         and outside of its own AS) and do appropriate path selection.
  388.         Paths that do not comply with policy requirements are not
  389.         considered further.
  390.  
  391.  
  392.  
  393.  
  394. BGP Working Group                                               [Page 7]
  395.  
  396. RFC 1268           Application of BGP in the Internet       October 1991
  397.  
  398.  
  399.       - Presence or absence of a certain AS or AS's in the path. By
  400.         means of information outside the scope of BGP, an AS may know
  401.         some performance characteristics (e.g., bandwidth, MTU, intra-AS
  402.         diameter) of certain AS's and may try to avoid or prefer them.
  403.  
  404.       - Path origin. A path learned entirely from BGP (i.e., whose
  405.         endpoint is internal to the last AS on the path is generally
  406.         better than one for which part of the path was learned via EGP
  407.         or some other means.
  408.  
  409.       - AS path subsets. An AS path that is a subset of a longer AS
  410.         path to the same destination should be preferred over the longer
  411.         path.  Any problem in the shorter path (such as an outage) will
  412.         also be a problem in the longer path.
  413.  
  414.       - Link dynamics. Stable paths should be preferred over unstable
  415.         ones. Note that this criterion must be used in a very careful
  416.         way to avoid causing unnecessary route fluctuation. Generally,
  417.         any criteria that depend on dynamic information might cause
  418.         routing instability and should be treated very carefully.
  419.  
  420. 6. Required set of supported routing policies.
  421.  
  422.    Policies are provided to BGP in the form of configuration
  423.    information.  This information is not directly encoded in the
  424.    protocol. Therefore, BGP can provides support for quite complex
  425.    routing policies. However, it is not required for all BGP
  426.    implementations to support such policies.
  427.  
  428.    We are not attempting to standardize the routing policies that must
  429.    be supported in every BGP implementation, we strongly encourage all
  430.    implementors to support the following set of routing policies:
  431.  
  432.       1. BGP implementations should allow an AS to control announcements
  433.          of BGP-learned routes to adjacent AS's.  Implementations should
  434.          also support such control with at least the granularity of
  435.          a single network.  Implementations should also support such
  436.          control with the granularity of an autonomous system, where
  437.          the autonomous system may be either the autonomous system that
  438.          originated the route, or the autonomous system that advertised
  439.          the route to the local system (adjacent autonomous system).
  440.  
  441.       2. BGP implementations should allow an AS to prefer a particular
  442.          path to a destination (when more than one path is available).
  443.          This function should be implemented by allowing system
  444.          administrators to assign "weights" to AS's, and making route
  445.          selection process to select a route with the lowest "weight"
  446.          (where "weight" of a route is defined as a sum of "weights" of
  447.  
  448.  
  449.  
  450. BGP Working Group                                               [Page 8]
  451.  
  452. RFC 1268           Application of BGP in the Internet       October 1991
  453.  
  454.  
  455.          all AS's in the AS_PATH path attribute associated with that
  456.          route).
  457.  
  458.       3. BGP implementations should allow an AS to ignore routes with
  459.          certain AS's in the AS_PATH path attribute.  Such function can
  460.          be implemented by using technique outlined in (2), and by
  461.          assigning "infinity" as "weights" for such AS's. The route
  462.          selection process must ignore routes that have "weight" equal
  463.          to "infinity".
  464.  
  465. 7. Conclusion
  466.  
  467.    The BGP protocol provides a high degree of control and flexibility
  468.    for doing interdomain routing while enforcing policy and performance
  469.    constraints and avoiding routing loops. The guidelines presented here
  470.    will provide a starting point for using BGP to provide more
  471.    sophisticated and manageable routing in the Internet as it grows.
  472.  
  473. Appendix A. The Interaction of BGP and an IGP
  474.  
  475.    This section outlines methods by which BGP can exchange routing
  476.    information with an IGP. The methods outlined here are not proposed
  477.    as part of the standard BGP usage at this time.  These methods are
  478.    outlined for information purposes only.  Implementors may want to
  479.    consider these methods when importing IGP information.
  480.  
  481.    This is general information that applies to any generic IGP.
  482.    Interaction between BGP and any specific IGP is outside the scope of
  483.    this section.  Methods for specific IGP's should be proposed in
  484.    separate documents.  Methods for specific IGP's could be proposed for
  485.    standard usage in the future.
  486.  
  487. Overview
  488.  
  489.    By definition, all transit AS's must be able to carry traffic which
  490.    originates from and/or is destined to locations outside of that AS.
  491.    This requires a certain degree of interaction and coordination
  492.    between BGP and the Interior Gateway Protocol (IGP) used by that
  493.    particular AS. In general, traffic originating outside of a given AS
  494.    is going to pass through both interior gateways (gateways that
  495.    support the IGP only) and border gateways (gateways that support both
  496.    the IGP and BGP). All interior gateways receive information about
  497.    external routes from one or more of the border gateways of the AS via
  498.    the IGP.
  499.  
  500.    Depending on the mechanism used to propagate BGP information within a
  501.    given AS, special care must be taken to ensure consistency between
  502.    BGP and the IGP, since changes in state are likely to propagate at
  503.  
  504.  
  505.  
  506. BGP Working Group                                               [Page 9]
  507.  
  508. RFC 1268           Application of BGP in the Internet       October 1991
  509.  
  510.  
  511.    different rates across the AS. There may be a time window between the
  512.    moment when some border gateway (A) receives new BGP routing
  513.    information which was originated from another border gateway (B)
  514.    within the same AS, and the moment the IGP within this AS is capable
  515.    of routing transit traffic to that border gateway (B). During that
  516.    time window, either incorrect routing or "black holes" can occur.
  517.  
  518.    In order to minimize such routing problems, border gateway (A) should
  519.    not advertise a route to some exterior network X via border gateway
  520.    (B) to all of its BGP neighbors in other AS's until all the interior
  521.    gateways within the AS are ready to route traffic destined to X via
  522.    the correct exit border gateway (B). In other words, interior routing
  523.    should converge on the proper exit gateway before/advertising routes
  524.    via that exit gateway to other AS's.
  525.  
  526. A.2 Methods for Achieving Stable Interactions
  527.  
  528.    The following discussion outlines several techniques capable of
  529.    achieving stable interactions between BGP and the IGP within an
  530.    Autonomous System.
  531.  
  532. A.2.1 Propagation of BGP Information via the IGP
  533.  
  534.    While BGP can provide its own mechanism for carrying BGP information
  535.    within an AS, one can also use an IGP to transport this information,
  536.    as long as the IGP supports complete flooding of routing information
  537.    (providing the mechanism to distribute the BGP information) and
  538.    onepass convergence (making the mechanism effectively atomic). If an
  539.    IGP is used to carry BGP information, then the period of
  540.    desynchronization described earlier does not occur at all, since BGP
  541.    information propagates within the AS synchronously with the IGP, and
  542.    the IGP converges more or less simultaneously with the arrival of the
  543.    new routing information. Note that the IGP only carries BGP
  544.    information and should not interpret or process this information.
  545.  
  546. A.2.2  Tagged Interior Gateway Protocol
  547.  
  548.    Certain IGPs can tag routes exterior to an AS with the identity of
  549.    their exit points while propagating them within the AS. Each border
  550.    gateway should use identical tags for announcing exterior routing
  551.    information (received via BGP) both into the IGP and into Internal
  552.    BGP when propagating this information to other border gateways within
  553.    the same AS. Tags generated by a border gateway must uniquely
  554.    identify that particular border gateway--different border gateways
  555.    must use different tags.
  556.  
  557.    All Border Gateways within a single AS must observe the following two
  558.    rules:
  559.  
  560.  
  561.  
  562. BGP Working Group                                              [Page 10]
  563.  
  564. RFC 1268           Application of BGP in the Internet       October 1991
  565.  
  566.  
  567.       1. Information received via Internal BGP by a border gateway A
  568.          declaring a network to be unreachable must immediately be
  569.          propagated to all of the External BGP neighbors of A.
  570.  
  571.       2. Information received via Internal BGP by a border gateway A
  572.          about a reachable network X cannot be propagated to any of
  573.          the External BGP neighbors of A unless/until A has an IGP
  574.          route to X and both the IGP and the BGP routing information
  575.          have identical tags.
  576.  
  577.    These rules guarantee that no routing information is announced
  578.    externally unless the IGP is capable of correctly supporting it. It
  579.    also avoids some causes of "black holes".
  580.  
  581.    One possible method for tagging BGP and IGP routes within an AS is to
  582.    use the IP address of the exit border gateway announcing the exterior
  583.    route into the AS. In this case the "gateway" field in the BGP UPDATE
  584.    message is used as the tag.
  585.  
  586. A.2.3 Encapsulation
  587.  
  588.    Encapsulation provides the simplest (in terms of the interaction
  589.    between the IGP and BGP) mechanism for carrying transit traffic
  590.    across the AS. In this approach, transit traffic is encapsulated
  591.    within an IP datagram addressed to the exit gateway. The only
  592.    requirement imposed on the IGP by this approach is that it should be
  593.    capable of supporting routing between border gateways within the same
  594.    AS.
  595.  
  596.    The address of the exit gateway A for some exterior network X is
  597.    specified in the BGP identifier field of the BGP OPEN message
  598.    received from gateway A via Internal BGP by all other border gateways
  599.    within the same AS. In order to route traffic to network X, each
  600.    border gateway within the AS encapsulates it in datagrams addressed
  601.    to gateway A. Gateway A then performs decapsulation and forwards the
  602.    original packet to the proper gateway in another AS
  603.  
  604.    Since encapsulation does not rely on the IGP to carry exterior
  605.    routing information, no synchronization between BGP and the IGP is
  606.    required.
  607.  
  608.    Some means of identifying datagrams containing encapsulated IP, such
  609.    as an IP protocol type code, must be defined if this method is to be
  610.    used.
  611.  
  612.    Note, that if a packet to be encapsulated has length that is very
  613.    close to the MTU, that packet would be fragmented at the gateway that
  614.    performs encapsulation.
  615.  
  616.  
  617.  
  618. BGP Working Group                                              [Page 11]
  619.  
  620. RFC 1268           Application of BGP in the Internet       October 1991
  621.  
  622.  
  623. A.2.4  Other Cases
  624.  
  625.    There may be AS's with IGPs which can neither carry BGP information
  626.    nor tag exterior routes (e.g., RIP). In addition, encapsulation may
  627.    be either infeasible or undesirable. In such situations, the
  628.    following two rules must be observed:
  629.  
  630.       1. Information received via Internal BGP by a border gateway A
  631.          declaring a network to be unreachable must immediately be
  632.          propagated to all of the External BGP neighbors of A.
  633.  
  634.       2. Information received via Internal BGP by a border gateway A
  635.          about a reachable network X cannot be propagated to any of
  636.          the External BGP neighbors of A unless A has an IGP route to
  637.          X and sufficient time (holddown) has passed for the IGP routes
  638.          to have converged.
  639.  
  640.    The above rules present necessary (but not sufficient) conditions for
  641.    propagating BGP routing information to other AS's. In contrast to
  642.    tagged IGPs, these rules cannot ensure that interior routes to the
  643.    proper exit gateways are in place before propagating the routes other
  644.    AS's.
  645.  
  646.    If the convergence time of an IGP is less than some small value X,
  647.    then the time window during which the IGP and BGP are unsynchronized
  648.    is less than X as well, and the whole issue can be ignored at the
  649.    cost of transient periods (of less than length X) of routing
  650.    instability. A reasonable value for X is a matter for further study,
  651.    but X should probably be less than one second.
  652.  
  653.    If the convergence time of an IGP cannot be ignored, a different
  654.    approach is needed. Mechanisms and techniques which might be
  655.    appropriate in this situation are subjects for further study.
  656.  
  657. References
  658.  
  659.    [1] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-
  660.        3)", RFC 1267, cisco Systems, T.J. Watson Research Center, IBM
  661.        Corp., October 1991.
  662.  
  663.    [2] Braun, H-W., "Models of Policy Based Routing", RFC 1104,
  664.        Merit/NSFNET, June 1989.
  665.  
  666. Security Considerations
  667.  
  668.    Security issues are not discussed in this memo.
  669.  
  670.  
  671.  
  672.  
  673.  
  674. BGP Working Group                                              [Page 12]
  675.  
  676. RFC 1268           Application of BGP in the Internet       October 1991
  677.  
  678.  
  679. Authors' Addresses
  680.  
  681.    Yakov Rekhter
  682.    T.J. Watson Research Center IBM Corporation
  683.    P.O. Box 218
  684.    Yorktown Heights, NY 10598
  685.  
  686.    Phone:  (914) 945-3896
  687.    EMail: yakov@watson.ibm.com
  688.  
  689.  
  690.    Phill Gross
  691.    Advanced Network and Services (ANS)
  692.    100 Clearbrook Road
  693.    Elmsford, NY 10523
  694.  
  695.    Phone: (914) 789-5300
  696.    Email: pgross@NIS.ANS.NET
  697.  
  698.    IETF BGP WG mailing list: iwg@rice.edu
  699.    To be added: iwg-request@rice.edu
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. BGP Working Group                                              [Page 13]
  731.